REMARKS 



Claim Rejections Under 35 U.S.C. § 101 

Claims 1-18 stand rejected under 35 U.S.C. § 101. Independent claim 1 has been 
amended to positively recite the particular machine to which the claim is tied. Claims 2-18 
depend (directly or indirectly) from claim 1, and therefore, Applicant believes that each of claims 
1-18 are statutory under 35 U.S.C. § 101 . 

Claim Refections Under 35 U.S.C. § 112 

Claims 2-4, 7-12, and 18 stand rejected under 35 U.S.C. § 1 12 as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. Claims 2 and 18 have been amended to clarify that geocodes associated with the 
first and second characteristics are spatially near, as requested by the Examiner. Applicant 
therefore believes that claims 2 and 18 as well as claims 3-4 and 7-12, which depend from claim 
2, are definite under 35 U.S.C. § 112. 

Claim Rejections Under 35 U.S.C. § 103 

Claims 1-18 stand rejected under 35 U.S.C. § 1 03(a) as being unpatentable over U.S. 
Publication No. 2002/0019699 ("McCarty") in view of U.S. Publication No. 2004/0183672 
("Krishan"). Applicant respectfully requests reconsideration since the proposed combination of 
McCarty and Krishan, assuming arguendo that the proposed combination is proper, fails to teach 
each feature required by the combination of features presented in claim 1 to one of ordinary skill 
in the art. 

For instance, claim 1 is directed to a method for ensuring accurate geocoding of an input 
location in an asset tracking system. As explained on pages 20-23 of the specification, the 
claimed invention involves ensuring that an input location is accurately geocoded before a 
geocode of the input location is forwarded to an asset (e.g., fire truck or police car) for response 
to the input location. This process increases the likelihood that the response will be directed to 
the correct location. Specifically, claim 1 requires receiving a first characteristic of an input 
location and at least one other characteristic of the input location. As explained in paragraph 
[0064] of the specification, these characteristics may include, for example, a street address, a 
city, a zip code, a county, a state, a phone number, a coordinate location, or a set of cross streets 
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associated with the input location. Claim 1 further requires generating a first geocode for the 
first characteristic and an additional geocode for at least one of the other characteristics, The 
first geocode is then compared with at least one of the additional geocodes. Based on that 
comparison, a determination is made regarding whether the first characteristic and one of the 
other characteristics identify a same location before a geocode of that same location is sent to 
one or more assets. 

In one example discussed on pages 27-28 of the specification, a citizen in the town 
awakes to the fire alarm and calls the fire department. A 91 1 operator answers the call and takes 
the citizen's street, address, 133 Main Street, and enters it into an address field 502 of a GIS 
system input sheet 500, as shown in Figure 5. The GIS system determines all variants of the 
word "main" and maps two locations having street names "Main" and "Mane" on a GIS xnap 
600, shown in Figure 6. At this point, there is a 50% level of confidence that a geocode of either 
location will accurately designate the citizen's home. This translates to a 50% level of 
confidence that a dispatched fire engine will be sent to the correct address. As a result, the GIS 
system seeks a second descriptive characteristic for use in accurately geocoding the citizen's 
location. For instance, the GIS system may employ caller ID to obtain the citizen's area code 
and phone number and enter them into a phone number field 512 of the input sheet 500, shown 
in Figure 5. While an area code 612 (Figure 6) includes both the "Main" and "Mane" addresses, 
the center of the area code is closer to the "Main" address. This additional characteristic raises 
the level of confidence to 55%, but the GIS system realizes that even further information is 
required to reach a threshold accuracy of 80%. Thus, the system prompts the 91 1 operator for an 
additional descriptive characteristic. The citizen provides the five digit zip code of the home, 
"11011," and the operator enters the zip code into the zip code field 506, shown in Figure 5. The 
GIS system maps the zip code in the GIS map of Figure 6, which shows that the zip code covers 
area 610. Only the "Main" address is located within the zip code area 610, and therefore, the 
level of confidence that the "Main" address is correct increases to 90%, which exceeds the 80% 
threshold. Thus, the GIS system identifies and marks the 133 Main address as the appropriate 
location to which to respond and alerts the closest fire engine accordingly. 

McCarty discloses a geographical information system for geographically locating 
potential customers and/or facilities relative to existing facilities and/or infrastructure for retail, 
wholesale, commercial, utilities, or other business purposes. Specifically, the system includes an 
address validation and geocode module 217. McCarty, Figure 2. The validation and geocode 
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module 217 receives a folly defined input address (e.g., city/state/zip code) and validates it by 
comparing the input address with address ranges within the United States Postal Service 
("USPS") address ZIP+4 database. If the database contains an exact match, the module 217 
outputs a "validated" address that is in standard format according to the USPS address ZIP+4 
database. The module 217 then geocodes the validated address on a rooftop level of precision, 
returning positional information (e.g., latitude and longitude coordinates, cartesian coordinates, 
spherical coordinates, polar coordinates) to a web server 103. McCartv. Paragraph [0077] and 
[Q079M0080]; Figures 2 and 5. If the address fails validation (i.e., the USPS database does not 
contain an exact match), the module 217 geocodes at the ZIP-9 level or the ZIP-5 level 
depending on the closest address match available and taking into account useful parameters 
within the user's particular industry (e.g., the center of the ZIP code area for a utility company, 
the center of population concentration for the ZIP code for a retail outlet). McCarty, Paragraphs 
[0079]-[0080]. The user then chooses one or more of a number of selection criteria of interest 
within the particular industry, such as, for example a rate center, wire center, and/or particular 
tei communication service provider switch in the telecommunications industry, demographics of 
the region in the sales industry, and regional distribution channels in the manufacturing industry. 
McCartv. Paragraphs [0081]-[0082]; Figure 5. Using the validated address and the selected 
criteria, the system returns either a map or text reflecting the locations of the various selection 
criteria in relation to the validated address. McCarty, Paragraphs [0083]-[00087]; Figures 6A-B. 

Contrasting the requirements of claim 1, McCarty does not disclose generating a first 
geocode for a first characteristic of an input location (e.g., a street address) provided to a GIS 
system and an additional geocode for at least one other characteristic of the input location (e.g., a 
nearby intersection) provided to the GIS system. McCarty also fails to disclose comparing the 
first geocode to at least one of the additional geocodes to determine if the first characteristic and 
at least one of the other characteristics identify a same location. As discussed above, McCarty 
discloses generating a single geocode that corresponds to a "validated" input address and then 
comparing that single geocode to the relative geographic location(s) of one or more sites that are 
of interest within the user's industry (e.g., distribution channels, telecommunications switches, 
telecommunications rate centers). Notably, the input address is not "validated" by comparing 
two or more geocodes associated with descriptive characteristics of the input address, but by 
simply verifying the fully defined input address via the ZIP+4 database maintained by the U.S. 
Postal Service. McCarty provides a map of "push pin" distances between well-defined locations 
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of interest. It does not determine an accurate geocode for an input location based on incomplete 
descriptors/characteristics for that location. 

Krishan does not overcome these failings. Krishan teaches an asset tracking system that 
tracks the movement of a portable object (e.g., computer, camera, camcorder, bicycle, scooter, 
motorcycle, piece of luggage, handbag, backpack) via an attached GPS tracking device. Krishan , 
Abstract; Paragraphs [00Q9]~[Q0! 1]. In this regard, Krishan does not teach any manner of 
geocoding in connection with an input address. 

Claim 1 also requires the step of allowing a geocode of the same location (i.e., the 
location identified by the first characteristic and at least one of the other characteristics) to be 
sent to one or more assets. While the Examiner failed to address this limitation in the Office 
Action, Applicant notes that neither MeCarty nor Krishan teach this element. First, MeCarty 
does not involve assets in any capacity. The single geocode associated with the validated input 
address is generated by and retained at the validation and geocode module 217 for the user's 
consideration and analysis. As discussed above, the user may use this geocode to gauge the 
relative locations of various business sites of interest and the user's verified address (i.e., the user 
sees that its retail store is within a few miles of several distribution centers and uses that 
information to design its distribution chain). The geocode is never sent to an external device of 
any kind. 

Krishan also fails to teach this limitation because, as discussed above, the purpose of 
Krishan is to track portable objects or assets. Thus, Krishan teaches obtaining location 
information for a portable object and sending it back to a centralized monitoring station 32. 
Krishan . Figure 3; Paragraph [0022]-[0G23]. In this regard, Krishan teaches the opposite of what 
is required by claim 1. Specifically, rather than sending a geocode for a same location to an 
asset, as required by claim 1 , Kri shan teaches sending a geographical location for an asset to a 
central monitoring station. Indeed neither MeCarty nor Krishan involve the concept of a 
geocode for a same location that accurately identifies an input location. 

Further, as the Examiner is aware, a proposed modification cannot render the prior art 
unsatisfactory for its intended purpose or change the principle of operation of a reference. See 
MPEP § 2143.01. Here, it is unclear how MeCarty and Krishan could be combined without 
modifying or destroying the intended function of one or both of these references. Specifically, if 
the asset tracking capability of Krishan were incorporated into the address presentation system of 
MeCarty, it is unclear how the MeCarty system would operate because it is configured to map 
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distances between fixed locations, and not to track moving targets relative to each other or to a 
fixed location. 

For these reasons, the proposed combination of McCarty and Krishan fails to teach each 
limitation required by claim 1. Thus, Applicant believes that claim 1 is patentable over the 
combination of McCarty and Krishan and respectfully requests that the Examiner withdraw the 
rejection and allow the claim. Further, claims 2-18 depend (directly or indirectly) from claim 1, 
and Applicant believes these claims are allowable for at least the reasons provided for claim 1. 

In addition, independent grounds support the patentability of amended claim 2, As 
amended, claim 2 requires the determining step of claim 1 to include verifying that the first 
geocode and at least one of the additional geocodes are spatially near. Neither McCarty nor 
Krishan teach this step. As discussed above, McCarthy teaches determining whether a single 
geocode associated with the input address is spatially near various business sites of interest (e.g., 
telecommunications switch, distribution routes), not whether two separate geocodes, both for 
characteristics associated with an input location, are spatially near. Indeed, McCarthy fails to 
teach the generation of more than one geocode for the input address, let alone the comparison of 
those geocodes to determine whether the geocodes are spatially near. Krishan does not remedy 
this failure because, as discussed above, Krishan involves determining a location for a portable 
object rather than determining an accurate geocode for an input location. 

For these reasons, Applicant believes that claim 2 is patentable over the proposed 
combination of McCarty and Krishan, even assuming that the combination is proper. Further, 
claims 3-4 and 7-12 depend from claim 2 and Applicant believes that these claims are allowable 
for at least the same reasons as provided for claim 1. 

CGndmwm 

Based upon the foregoing, Applicant believes that all pending claims are in condition for 
allowance and such disposition is respectfully requested. In the event that a telephone 
conversation would further prosecution and/or expedite allowance, the Examiner is invited to 
contact the undersigned. 
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Respectfully submitted, 

MARSH FISCHMANN & BREYFOGLE LLP 



A. Huskey C J 
Registration No. 59,087 
8055 E. Tufts Avenue, Suite 450 
Denver, CO 80237 
Telephone: 720-562-5509 
Facsimile: 720-562-5519 
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